Visual Studio warning fixes and improvements#27939
Conversation
9d37206 to
969e097
Compare
| # Add a post-build event to deploy the application to the output folder. Same as building the INSTALL target. | ||
| #add_custom_command( | ||
| # TARGET MuseScoreStudio POST_BUILD | ||
| # COMMAND ${CMAKE_COMMAND} -DBUILD_TYPE=$(Configuration) -P cmake_install.cmake |
There was a problem hiding this comment.
Not ${Configuration}?, curly braces?
There was a problem hiding this comment.
No, we don't want the value of the CMake variable Configuration here. Instead we want $(Configuration) to go verbatim to the post-build event where Visual Studio when running it will replace $(Configuration) with the current build configuration. Ninja does not like the $ but why? We have the same pattern elsewhere. I am trying to see if putting it inside double quotes will make everyone happy. Or doubling the $.
There was a problem hiding this comment.
I realize it's too late now, but it might have worked for this to be the CMake generator expression $<CONFIG> :)
There was a problem hiding this comment.
Not too late to put that into a new PR ;-)
BTW: any idea how to do a change to the same effect for 3.x? A simple copy/paste does not work
(see my attempt in Jojo-Schmitz#931)
There was a problem hiding this comment.
See my reply over there
There was a problem hiding this comment.
Thanks, I was particularly thick here...
4b9180d to
93068a1
Compare
93068a1 to
d956d3d
Compare
|
Thanks Casper. What is needed to merge it? I am wondering if we want to make the "SetupBuildEnvironment.user.cmake" change for everyone? Currently it is for MSVC only. |
|
I was waiting for the checks to finish, but they have done so by now. But yes, perhaps it's a good idea to move that if/include to the end of the file, so that it can be used with all compilers. Now that we're discussing it anyway, what are you currently using it for? (Just wondering if it's something we should maybe consider doing by default for everyone) |
|
I added it because I want to disable all optimizations in my RelWithDebInfo configuration. |
|
Ah okay. Anyway, for consistency, let's make it also available with non-MSVC, and then I'll merge it. |
d956d3d to
add5d9f
Compare
|
Updated. Many thanks! |
reg.: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library (LNL4098) Esp. (only?) in Debug builds. (Partial) Backport of musescore#27939
reg.: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library (LNK4098), esp. (only?) in Debug builds. (Partial) Backport of musescore#27939
(Partial) Backport of musescore#27939
(Partial) Backport of musescore#27939
(Partial) Backport of musescore#27939
(Partial) Backport of musescore#27939
4 participants
This PR:
Stops "defaultlib 'LIBCMT' conflicts with use of other libs" linker warning on all EXE projects
Also stop "M_LN2 macro redefinition" compiler warning.
Adds a post-build event to the MuseScoreStudio project to deploy the app to the output folder (same as what the INSTALL target does). This was a missing step that every Visual Studio user struggled with individually. This change makes the INSTALL target, when built, deploy the app twice but everything will already be up-to-date and this is a much less severe thing than the code changes not getting automatically deployed when building MuseScore.
Adds the possibility of having a
SetupBuildEnvironment.user.cmakefile in the same folder asSetupBuildEnvironment.cmaketo allow individual users to override settings as they see fit. Some recent changes have made the Debug build configuration in Visual Studio less pleasant to use and switching to RelWithDebInfo also comes with compromises. I think this per-user file will give users more flexibility. Of course, if there is an agreement that a user override change is good enough for all Visual Studio users, it will be included in the globalSetupBuildEnvironment.cmake.